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Call for Papers: USENIX C++ 

USENIX is pleased to host its third C++ 
conference in Washington, D.C,, April 22-25, 
1991. Monday and Tuesday will offer tutorials; 
Wednesday and Thursday are technical sessions. 
This announcement provides early information 
about the date of events as well as persons to 
contact for further information. The pre¬ 
registration packet containing detailed Confer¬ 
ence information and hotel reservation informa¬ 
tion will be mailed in February, 1991. 

The meeting headquarters will be the Wash¬ 
ington, D.C, Sheraton Hotel. 


Schedule of Events 

Tutorials 
April 22-23 

Introductory and intermediate tutorials will 
be provided on the C++ language, libraries, and 
environments. Please contact the program chair if 
you wish to propose to give a tutorial or to suggest 
a topic you would like to see covered in a tutorial. 

Technical Sessions 
April 24-25 

The technical sessions will cover the spec¬ 
trum of recent research, development, and ex¬ 
perience developing C++ software. Papers are 
solicited on all aspects of C++, including: 

Language features 
Compilers 

Programming environments 
Class libraries 
Experiences 


Conference 

Extended abstracts of at most 2500 words (10 
pages double-spaced) should be submitted elec¬ 
tronically (PostScript, troff, or TeX) or eight (8) 
copies on paper to the program chairman by 
November 30, 1990. Authors will be notified of 
acceptance by January 25, 1991 and final camera- 
ready papers are due March 1, 1991. 

Queries about the technical program and all 
submissions should be directed to the program 
chairman: 

Mark Linton 
Silicon Graphics, Inc. 

2011 N. Shoreline Blvd. 

P.O. Box 7311 

Mountain View, CA 94039-7311 
Telephone (415) 335-7204 
FAX (415) 965-7651 
linton@sgi.com 

Program Committee: 

Mark Linton, 

Silicon Graphics, Chair 

Keith Gorlen, 

National Institutes of Health 

Doug Lea, 

SUNY Oswego 

Steve Reiss, 

Brown University 

Vince Russo, 

Purdue University 

Rob Seliger, 

Hewlett-Packard 

Jonathan Shopiro, 

AT&T Bell Laboratories 

Michael Tiemann, 

Cygnus Support 

Jim Waldo, 

HP Apollo 


September/October 
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IEEE COMPUTER SOCIETY 


Call for Participation: Symposium on Experiences with 
Distributed and Multiprocessor Systems (SEDMS) 


Atlanta, GA, March 21-22, 1991 

Sponsored by the USENIX Association in association with the NSF/Purdue/Florida Software 
Engineering Research Center, in cooperation with ACM SIGCOMM and SIGOPS 
and the lEEE-CS Technical Committees on Distributed Processing, Operating Systems, and 
Software Engineering. 


Goals 

The goal of this symposium is to bring 
together individuals who have built, are build¬ 
ing, or will soon build distributed and mul¬ 
tiprocessor systems, especially operating 
systems. The symposium will feature full 
presentations and (perhaps) panels on aspects 
of building, testing, debugging, and using these 
systems. We will provide a forum for in¬ 
dividuals to exchange information on their ex¬ 
periences, both good and bad, including ex¬ 
periences with coding aids, languages, distri¬ 
buted debugging tools, prototyping, reuse of 
existing software, performance analysis, and 
lessons learned from use of such systems. 
Extra-long breaks between sessions and work- 
in-progress presentations will be provided to 
facilitate a workshop-like atmosphere during 
the symposium. 

Submissions 

Ten copies of each submission or panel 
proposal should be sent to the program com¬ 
mittee chair (address below) to arrive no later 
than November 19, 1990. Submissions of full 
papers are invited on any topics related to the 
theme of the symposium. The committee will 
give preferential consideration to submissions 
describing experiences with actual systems - 
papers describing theoretical work or simula¬ 
tions are unlikely to be accepted. Panel 
proposals should include a description of the 
relevance to the goals of the SEDMS, and the 
qualifications of the participants suggested. 


Important Dates 

Submissions due Nov. 19, 1990 

Notifications mailed Jan. 7,1991 

Camera ready copy due Jan. 30, 1991 

For further information, contact: 

General Chair 

George Leach 
AT&T Paradyne 
MS LG-133 
PO Box 2826 
Largo, FL 34649-2826 

(813) 530-2376 
reggie@paradyne.com 

Program Chair 
Gene Spafford 

Software Engineering Research Center 
Dept, of Computer Sciences 
Purdue University 
W. Lafayette, IN 47907-2004 

(317) 494-7825 
spaf@cs.purdue.edu 

Program Committee 

John Barr (Motorola, Inc.) 

Bharat Bhaigava (Purdue University) 

David Cohn (Notre Dame) 

George Leach (AT&T Paradyne) 

Mike O’Dell (Bellcore) 

Karsten Schwan (Georgia Tech) 

Michael Scott (University of Rochester) 

Roger Shultz (Rockwell International) 

Gene Spafford (Purdue University/SERC) 
Satish Tripathi (University of Maryland) 
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General chair; 

Luis Felipe Cabrera 
IBM ARC 

Local arrangements: 

Noah Mendelsohn 
IBM Cambridge 

Publicity chair: 

Ken Kane 

SUN Microsystems 

Publications chair; 

Dorothy Marsh 

Cornell University 

Hardware exhibits: 

Pat Mantey 

U, C. Santa Cruz 

Program co-chairs: 

Ken Birman 

Cornell University 
Keith Marzullo 

Cornell University 

Program committee: 

Anita Borg 
DEC WRL 
Thomas Joseph 
Olivetti ORC 
Gail Kaiser 

Columbia University 
Susan Owicki 
DEC SRC 
Mike Powell 

SUN Microsystems 
Marc Rozier 

Chorus Systems 
M. Satyanarayanan 

Carnegie-Mellon University 
Frank Schmuck 
IBM ARC 
Henry Sowizral 
NASA RIACS 
Doug Terry 
Xerox PARC 
Walter Tichy 

Universitdt Karlsruhe 
Robbert Van Renesse 
Vrije Universiteit 
Robin Williams 
IBM ARC 
Paulo Verissimo 
IN ESC Portugal 
Greg Zack 
Xerox DRI 


CALL FOR PAPERS 

Third IEEE Conference On Computer Workstations: 
Accomplishments And Challenges 

Sponsored by the IEEE Technical Committee on Operating Systems (TCOS) 

The Sea Crest Resort, Falmouth, Cape Cod (Massachusetts) 

May 15-17, 1991 

As we enter the 1990’s, changes in technology will require rethinking the role of the 
workstation in the computing environment. Gigabit communication, desktop parallel 
computing, and multimedia applications are now emerging. The key to effective comput¬ 
ing in this new world is the interface between the user and the computing environment; 
the workstation. What challenges must be overcome to make effective use of emerging 
technologies? CCW ’91 seeks to foster dialogue between builders of workstation-based ap¬ 
plications and technological innovators. Papers may focus on experiences with ambitious 
applications as well as on research topics. Topics include: 

• Design of workstation computing environments 

• Workstation and system architecture 

• Application and system management 

• User interface technologies 

• Exploiting parallelism and massive memory 

• Network support for high performance distributed computing 

• Computer-aided software engineering 

• Information management systems 

• Real-time sensing and control 

• Issues of scale 

• Innovative ideas and technologies 


Papers should be no longer than about 5000 words (20 double-spaced pages), and must 
be received by September 15, 1990, Authors will be notified of acceptance by December 
1, 1990, and final camera-ready copy is due by January 15, 1991. Both technical and 
case-study papers are solicited; case studies should describe existing systems and include 
performance or operational data where practical. 

The conference will also include a poster session for discussing work in progress. Individ¬ 
uals with a specific interest in participating in the poster session are invited to submit 
a one-page abstract describing their project. In addition, the program committee will 
invite the authors of some of the submitted papers to present their work in the poster 
session. 

Send five copies of each submission to: 

Prof. Keith Marzullo 

Program co-chair, CCW' '91 

Department of Computer Science, Upson Hall 

Cornell University 

Ithaca NY 14853 

Important dates: 

Submissions due September 15, 1990 

Notification of acceptance December 1, 1990 

Camera-ready copies due January 15, 1991 


September/October 
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E U U G 


European UNIX" systems User Group 

PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS 

EUUG Spring *91 Conference 
and Exhibition at 


Tiomso, Norway 
20-24 May, 1991 



Preliminary Announcement ' -- 

The NUUG will host the Spring ’91 European UNIX Systems User Group Technical Conference in 
Troms0, Norway, Europe 

The Conference will concentrate on Distributed Open Systems in Perspective. In addition to an overview 
of the issues involved in the design of distributed open systems the conference will address problems 
encountered and solutions found when distributed open systems are employed. 

The three day Conference with commercial Exhibition on Open Systems, UNIX and related subjects will 
be accompanied by Technical Tutorials on Monday 20th and Tuesday 21st May, followed by the main 
conference on Wednesday 22nd to Friday 24th May. 

A pre-conference registration pack containing detailed information will be issued in February, 1991. 

Call for Papers 

The EUUG invites papers from those wishing to present their work Full papers or extended abstracts 
must be submitted. All submitted papers will be referred to be judged with respect to their quality, 
originality and relevance. 


Suggested subject areas include, but are not limited to: 


^ The Applica bilitp of Distributed ik' Distributed Applica tions 

Open Systems ir Tools 

★ Security it Heterogenous Distributed Environments 

^ Reliability it Distributed Databases 

★ Transparency it User Interfaces in Distributed Environments 

it Interoperability 

For further details, contact: 

EUUG Central office: 

European Unix® systems User Group 

Owles Hall, Buntingford, Herts SG9 9PL, UK. 

Phone: ( + 44) 763 73039 Fax: (+ 44) 763 73255 Network Address: euug@Eu.net 
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Tenth International Conference on Computer Communication 


New Delhi, India, November 4-8, 1990 

ICCC-90 is the tenth conference of the In¬ 
ternational Council for Computer Communica¬ 
tion (ICCC). ICCC-90 will provide an important 
and prestigious forum for presentation, discussion 
and debate. Topics discussed will include all as¬ 
pects of computer communication, including tech¬ 
nical, scientific, social, policy making, business 
and legal aspects. 

The topics for approximately 90 papers to be 
presented include: 

* Communication aspects of: Distributed Op¬ 
erating Systems, Expert Systems, Office and Fac¬ 
tory Information Systems, Robotics, Security and 
Privacy, Standards, Videotext, Work Stations 

^Electronic Funds Transfer, Human Factors, 

Legal Aspects, Regulatory Issues 

*Data Communication in ISDN, Optical 
Data Transmission and Switching, Packet Radio, 

2.10.1 BSD Release Available 

The second release of 2.10BSD is available. 

It has been designated 2.10.1. Although the 
changes are fairly simple to describe, they cover 
large portions of the distribution. Most will not be 
visible to either users or administrators; specifi¬ 
cally, no recompilation is necessary. Administra¬ 
tors should be aware that the 4.3BSD disk quota 
system is now available. Due to address space 
considerations, however, it is expensive to run. 

Also, the source for the on-line manual pages has 
been rearranged as per the 4.3BSD-Tahoe re¬ 
lease. 

The major change, and the reason for the 
second release, is an extensive reworking of the 
kernel to move the networking into supervisor 
space. This move eliminated most, if not all, of 
the instabilities seen in the original networking 
provided with 2.10BSD; it also doubled the speed 
of, for example, file transfer. As encouragement 
to sites that encountered difficulties in using the 
networking in the first release, or encounter dif¬ 
ficulties in this release, we have beta sites that 
have been running for months without crashing, 
as well as sites with fifty nodes. We are, however, 
still suspicious of the DEQNA driver . . . 


Protocol Specification and Verification, Protocol 
Conversion, Satellite Data Communication 

*Academic Networks, Corporate Networks, 
Local Area Networks, Networks Management 
and Operation, Packet Switching, Open Systems 
Interconnection (OSI) 

For further information, registration etc., 
please contact 

S. Ramani 

Chairman, Programme Committee, ICCC-90 
National Centre for Software Technology 
Gulmohar Cross Road No. 9 
Bombay 400 049, INDIA 

Phone: -h91(22)6200590/6201606 

Telex: +81(11)78260 NCST IN 

Email: iccc90@ncst.in OR iccc90@ncst.ernet.in 


In application land, many missing pieces of 
the 4BSD distribution have been added, most 
notably the FORTRAN compiler and library and 
the line printer sub-system. Many other programs 
have had minor (and not-so-minor) fixes applied. 

Keith Bostic 
Casey Leedom 

Because the changes to the kernel are major, 
no “upgrade” tape will be available. 2.10.1 BSD 
is only available as source, to appropriate licens¬ 
ees of V7, System III, System V, or 2.9BSD. The 
cost is $200, prepaid. 

The release consists of two 2400 foot, 1600 
BPI tapes (approximately 80Mb) and approxi¬ 
mately 100 pages of documentation. If you re¬ 
quire 800 BPI tapes, please contact USENIX. To 
order 2.10.1 contact the USENIX Association, 
Tel: 415 528-8649, EMail: office@usenix.org. 

If you have technical questions about the 
release, please contact Keith Bostic at: 
keith@okeeffe.berkeley.edu 415 642-4948. 

NOTE: There are a few copies of 2.9BSD avail¬ 
able. If you do not have split I&D and want to 
run UNIX on your PDP-ll/x, contact USENIX. 


September/October 
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Long-Term Calendar of UNIX Events^ 


1990 Oct 17-19 
1990 Oct 22-26 
1990 Oct 29-Nov 2 
1990 Oct 31-Nov 1 
1990 Nov 5-9 
1990 Nov 8 
1990 Nov 14-16 
1990 Nov 15 
1990 Nov 15-16 
1990 Dec 2-6 
1990 Dec 4-5 
1990 Dec 10-12 
1990 Dec 10-14 

1990 Dec 17-19 

1991 Jan 7-11 
1991 Jan 16-18 
1991 Jan 21-25 
1991 Jan 22-25 
1991 Feb 18-22 
1991 Mar 21-22 
1991 Apr 15-19 
1991 Apr 22-25 
1991 May 6-10 
1991 May 15-17 
1991 May 20-24 
1991 Jun 10-14 
1991 Jun 16-19 
1991 Jul 8-12 
1991 Jul 15-17 
1991 Sep 16-20 
1991 Oct 21-25 
1991 Dec 

1991 Dec 8-11 

1991 Dec 9-13 

1992 Jan 13-17 
1992 Jan 20-24 
1992 Jan 21-24 
1992 Spring 
1992 Apr 20-24 
1992 May 4-8 
1992 Jun 8-12 
1992 Jun 21-24 
1992 Jul 13-17 

1991 Autumn 

1992 Oct 19-23 

1993 Jan 25-29 
1993 Mar 15-18 
1993 Jun 21-25 


*Large Installation Sys. Admin. 
EUUG 

Soviet UNIX Users’ Group 
UNIX Expo 

Computer Communication Conf. 

Open Systems, NLUUG 

UNIX EXPO ’90 UniForum 

POSIX APP Workshop 

16th JUS Symposium 

Sun User Group 

JUS UNIX Fair ’90 

UNIX Asia ’90 

DECUS 

UKUUG 

IEEE 1003 

♦Software Devel. Environments 
USENIX 
UniForum 
DECUS 

*Symp. Distrib. Multiproc. Sys. 
IEEE 1003 
USENIX C-H- 
DECUS 

IEEE TCOS Cptr Workstations 

EUUG 

USENIX 

Sun User Group 

IEEE 1003 

UKUUG 

EUUG 

IEEE 1003 

UKUUG 

Sun User Group 

DECUS 

IEEE 1003 

USENIX 

UniForum 

EUUG 

IEEE 1003 

DECUS 

USENIX 

Sun User Group 

IEEE 1003 

EUUG 

IEEE 1003 

USENIX 

UniForum 

USENIX 


Colorado Springs, CO 

Nice, France 

Moscow, USSR 

New York, NY 

ICCC; New Delhi, India 

Ede, Netherlands 

Stockholm, Sweden 

NIST; Gaithersburg, MD 

Osaka, Japan 

San Jose, CA 

Tokyo, Japan 

Sinix, Singapore 

Las Vegas, NV 

Cambridge, UK 

New Orleans, LA 

Grand Kempinski, Dallas, TX 

Grand Kempinski, Dallas, TX 

Infomart, Dallas, TX 

Ottawa, Ont. 

Atlanta, GA 
Chicago, IL 
Washington, D.C. 

Atlanta, GA 
Falmouth, MA 
Tromso, Norway 
Opryland, Nashville, TN 
Atlanta, GA 

Liverpool, UK 
Budapest, Hungary 

Edinburgh, UK 
San Jose, CA 
Anaheim, CA 

Hilton Square, San Francisco, CA 
Moscone Center, San Francisco, CA 
Jersey, UK 

Atlanta, GA 
San Antonio, TX 
Washington, DC 

Amsterdam, Netherlands 

San Diego, CA 
San Francisco, CA 
Cincinnati, OH 


^Compiled with the assistance of Alain Williams of the EUUG, Susanne Smith of Windsound Consulting, and John 
Quarterman of Texas Internet Consulting. 

♦USENIX Workshops 
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USENIX Staff Changes 

Beginning this Fall, the Association will no longer 
have an office in Boulder, Colorado. John Don¬ 
nelly, the Exhibit Manager and Tutorial Coordi¬ 
nator, has decided to pursue other interests. 
Michael McLaughlin, his assistant, will be return¬ 
ing to his studies at the university full-time. John 
will be consulting in the seminar planning, exhibit 
management and meeting planning arenas. He 
can be reached at 858 Pimlico Court, Boulder, 
CO 80303; Tel: 303-494-8495 or 303-494-2607; 
email: j ohnd©boulder. Colorado. edu. 

The functions previously handled by the 
Boulder office will now be performed by two 
individuals. The Association is pleased to an¬ 
nounce that it has hired Daniel Klein as its Tu¬ 
torial Coordinator and Cynthia Deno as Exhibit 
Manager. 

As many of you are aware, Dan has been 
very active in the Association, both as a tutorial 
speaker and as the program chairman for the 
Winter ’90 technical conference. Dan is currently 
employed by the Software Engineering Institute 
in Pittsburgh. The tutorial program has become 
an important feature of the USENIX conferences 
and offers a leading edge forum for educating 
UNIX professionals. Dan is actively seeking new 
topics and speakers, and an announcement will 
appear in the next issue oi ;login:. He can also be 
reached via email: dvk@usenix.org. 


Computing Systems Special Issue 

If you were paid up member as of May 1990, you 
should have just received Computing Systems vol¬ 
ume 3, number 2. This issue is accompanied by a 
compact disc which includes both classical reper¬ 
tory and original works. 

The music on the CD was created by Michael 
Hawley at the MIT Media Laboratory and Peter 
Langston while he was at Bellcore. Pieces include 
“Empty Bed Blues” by Johnson, “Some Velvet 


Cynthia Deno has many years of experience 
in conducting large-scale direct mail and manag¬ 
ing journal publishing programs. She was most 
recently direct mail manager at ETR Associates 
in Scotts Valley, CA where she planned publica¬ 
tions sales and conference promotion campaigns. 
Prior to this she has many years of experience in 
marketing and project management with such 
firms as Springer-Verlag, Academic Press and the 
University of California Press. Cynthia’s overall 
marketing and organizational experience will be 
a welcome addition to the management of the 
Association’s conferences. She is actively seeking 
exhibitors for the Summer 1991 Conference and 
Exhibition. If you or your company would like 
information on demonstrating your latest prod¬ 
ucts to the USENIX community, please contact 
our Exhibit Manager either by email: 
cynthia@usenix.org or phone: 408-335-5646. 

If you’ve phoned the USENIX Conference 
office lately, you’ll notice a new voice, namely, 
Bernie Grunewald. She previously was an office 
manager for a high tech computer company. 
Bernie, as well as Marilynn Allemann, assist our 
conference coordinator, Judy DesHarnais, in 
fielding your questions concerning upcoming con¬ 
ferences and workshops, as well as providing sup¬ 
port at the meetings. 


Morning” by Lee Hazelwood, Liszt’s “Totenan- 
tanz” played by Jorge Bolet and the London Sym¬ 
phony Orchestra, and “Percusa Waltz” by Peter 
Langston. 

Single copies, including the CD, are available 
for $11,00. To place an order, contact the Uni¬ 
versity of California Press, 2120 Berkeley Way, 
Berkeley, CA 94720, 415/642-4191. 
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Report to USENIX and EUUG on ISO/IEC JTC1/SC22AVG15 
(POSIX) Meeting 
June 11-15, 1990 


Dominic Dunlop 

The Standard Answer Ltd. 

Introduction 

Working Group 15 of Subcommittee 22 of 
Joint Technical Committee 1 of the International 
Organization for Standardization and the Inter¬ 
national Electrotechnical Commission (ISO/IEC 
JTC1/SC22AVG15), or, more briefly, the ISO 
POSIX working group, met in Paris, France, from 
the 12th to the 15th of June. The meeting was 
hosted by AFNOR, (Association fran^aise de 
normalisation), the French national standards 
body, at its offices in La Defense, a high-rise 
business district a brisk train-ride away from the 
city centre, and was preceded on 11th June and 
the morning of the 12th by meetings of the rap¬ 
porteur groups on conformance testing, interna¬ 
tionalization and security. Attendance was good, 
with thirty “experts” (as the ISO Directives style 
us) representing nine countries, plus the Euro¬ 
pean Community. 

I was present at the main meeting and at the 
internationalization rapporteur group as an ob¬ 
server with the brief of reporting back to you. 
This report is the fourth jointly commissioned by 
the European UNIX systems User Group 
(EUUG) and USENIX. As usual, it’s a little im¬ 
precise in its references to ISO. Strictly, most of 
these should be to JTCl, or to some part of JTCl. 
Where precision is needed, I use it and give an 
explanation, but for the most part I refer simply 
to ISO, so as to avoid getting bogged down in 
unnecessary detail. If you have any comments, or 
need clarification or further information, please 
contact me at the mail address above. 

First, a summary of the most important as¬ 
pects of the meeting: 

Summary 

• POSIX.1, the operating system interface 
standard, should be published as international 
standard 9945-1 Real Soon Now. As I write, the 
ballot on the document has yet to close, but it 


seems unlikely that any of the twenty countries 
voting will oppose acceptance. The meeting iden¬ 
tified a number of trivial editorial changes to the 
current draft international standard, and these, 
taken together with continuing nit-picking com¬ 
ments from ISO’s central secretariat, should re¬ 
sult in a document which ISO will print. Its tech- 
pical content will be very close to that of ANSI/ 
IEEE Std. 1003.1:1988, so implementors follow¬ 
ing the U.S. standard can be assured of ISO com¬ 
pliance when 9945-1 finally sees the light of day. 

• POSIX.2, the shell and tools standard, 
faces a bumpier ride before becoming interna¬ 
tional standard 9945-2. In an ISO ballot on ac¬ 
ceptance of draft 9 of IEEE 1003.2 as a draft 
international standard, six countries voted 
against, with just five in favour. This is more of 
an embarrassment than a set-back: hindsight sug¬ 
gests that it was just too early to hold a ballot. 

• Showing its increasing concern and frustra¬ 
tion at the lack of apparent progress within the 
IEEE on a (programming) language-independent 
version of the POSIX operating system interface 
standard, WG15 has refused to “register” the 
current, largely language-independent, draft of 
the 1003.4 realtime extension standard on the 
grounds that it makes little sense to have 
language-independent extensions to a base stan¬ 
dard which is specified in terms of the C language. 
Similarly, the group failed to register 1003.5 (Ada 
binding) and 1003.9 (FORTRAN-77 binding) be¬ 
cause POSIX. 1 lacks an explicit service definition 
to which they can bind. 

• The failure to register these documents 
causes a hiccup—albeit a discreet one—in the 
synchronization between IEEE and ISO POSIX 
standardization schedules. In the hope of avoiding 
such situations in the future, an informal “speak 
now, or forever hold your peace” mechanism has 
been put in place, allowing the international com¬ 
munity to comment on the subject area, format, 


10 


September/October 



;login: 15:5 


presentation and approach of IEEE documents at 
an early stage in their preparation. 

• Had it not been for this upset, the working 
group would have adopted a firm synchronization 
plan so as to ensure that the work of IEEE and 
of ISO is closely coordinated in the future. As it 
is, the “U.S. member body”—ANSI—has been 
asked to provide a revised plan for the working 
group’s October meeting in Seattle. 

• The Open Software Foundation, UNIX In¬ 
ternational and X/Open are cooperating on a 
common approach to conformance testing, known 
as Phcenix. Governmental organizations with a 
strong interest in the field, such as the National 
Institute for Science and Technology (NIST) and 
the Commission of European Communities 
(CEC), seem broadly to welcome this move— 
even if the unaccustomed show of tripartite unity 
is, as one security rapporteur put it, “a bit 
spooky”. 

• At an evening reception hosted by AFUU 
(Association fran^aise des utilisateurs d’UNIX), 
the French UNIX users’ group, Mike Lambert of 
X/Open said that “our hand is extended” to the 
international standardization community, with 
which his organization hopes to work in finding 
some more timely and responsive way of dehv- 
ering formal consensus standards for open sys¬ 
tems. The definition of this mechanism is left as 
an exercise for the reader—or for the interna¬ 
tional standards community. Perhaps Mike has 
come to realize that standardizers too are prone 
to the Not Invented Here syndrome, and so must 
believe that they thought of something themselves 
before they can accept it. 

• Jiist to keep us all on our toes, ISO has 
updated its Directives, with the result that the 
procedure for turning a base document—such as 
one of the IEEE drafts—into an international 
standard is subtly changed. We now have to forget 
about Draft Proposals, and turn our minds instead 
to Working Drafts and Committee Drafts. Sigh 

The rest of this report gives more detail most 
of these topics. 

9945-1—Operating System Interface 

You may recall from my report of WG15’s 
last meeting in October, 1989, that the group had 


in effect told ISO’s central secretariat that, while 
the then-current draft of IS 9945-1 was not per¬ 
fect, it was, in the group’s opinion, good enough 
to publish, particularly since we’d undertake to fix 
things up on short order, allowing an improved 
version to be published within a year of the first 
edition. 

This proposal did not fly. Firstly, the central 
secretariat (now dynamically known as ITTF, the 
Information Technology Task Force), refused to 
publish a document that looked much more like 
an IEEE standard than an ISO standard; sec¬ 
ondly, they deemed the changes needed to polish 
up the draft to be sufficiently great that it should 
go out to ballot again in order to provide a formal 
check that it was still acceptable to the group. This 
was duly done; the ballot closed on 29th June, and 
is expected to pass very comfortably. 

Nevertheless, the ballot gave people the op¬ 
portunity to comment formally on the document 
again, with the result that a number of small 
bug-fixes and clarifications were suggested, and 
were accepted for incorporation into the draft. 
We judge—and we hope that ITTF agrees—the 
changes are strictly editorial, and so will not merit 
yet another ballot. ITTF, which, in discussion 
with the IEEE, had slightly bent its drafting and 
presentation rules so as to come up with a com¬ 
promise satisfactory to both parties, also sug¬ 
gested further changes, some in areas that we 
thought had already been addressed. This is a 
cause for concern: the prospect of the standard 
never being published because its layout and lan¬ 
guage do not meet some ill-defined guidelines 
does not appeal. Consequently, we are seeking 
“written harmonized editorial requirements” 
from the IEEE and ITTF. 

The ballot also produced a number of sug¬ 
gestions in the area of internationalization, such 
as how to handle (and indeed, how to refer to) 
wide, or multi-byte, characters. To have acted on 
these comments would have changed the technical 
content of the draft standard—the equivalent of 
sliding down a snake in the game that leads to 
eventual publication. Happily, those who sug¬ 
gested the changes were content to leave these 
issues for the second edition of the standard, 
rather than further delay the first edition. 
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The single exception that we could get away 
with was to replace Annex E’s^ example inter¬ 
national profile for the hypothetical (and ex¬ 
tremely odd) land of Poz with a real example for 
the (only slightly odd) country of Denmark. Al¬ 
though this is a large change, it can be made 
because the annex (ISO-speak for appendix) is 
“non-normative”; that is, it is an explanatory ex¬ 
ample rather than a part of the official standard. 

Messaging, an issue which is currently exer¬ 
cising the minds of those concerned with the next 
edition of the 1003.1 standard^^^, was also passed 
over by WG15: nobody had a strong preference 
for either the X/Open proposal or the UniForum 
proposal, so 1003.1 will have to handle the issue 
without guidance from the ISO working group. 

Where all does this leave us? With no pub- 
hshed international standard as yet, but with a 
very good prospect of having one this year. Until 
it arrives, keep using the bilious green book, 
IEEE std. 1003.1:1988^, as its technical content is 
very close to that of the eventual ISO standard. 

9945-2—Shell and Tools 

Earlier in the year, there had been a ballot 
on moving forward draft proposal (DP) 9945-2, 
Shell and utility application interface for computer 
operating system environments, to become a draft 
international standard (DIS). Basically, while a 
DP is allowed—even expected—to differ consid¬ 
erably from the final international standard, a DIS 
is expected to match both the format and contents 
of the ultimate standard very closely^. That the 
ballot was six against to just five for (with nine 
countries not voting) indicates that the consensus 
is that 9945-2 has to go through quite a few more 
changes before it can be acceptable as an inter¬ 
national standard. 

Many of these changes concern internation¬ 
alization, as this topic affects POSIX.2 consider¬ 
ably more than POSIX.l. For example, the ex¬ 
ample Danish national profile to be incorporated 
into 9945-1 is just a part of the work that DS 
(Dansk Standardiseringrad) has done on the 
topic; the result affects 9945-2. There is also an 
unresolved issue concerning the definition of col¬ 
lation sequences (sorting orders) for international 
character sets. Utilities such as sort clearly need 
to know about collation sequence, and so do the 


regular expression-handling utilities and functions 
defined by POSIX.2. The problem is that nobody 
in ISO seems to want to handle the matter. In 
particular, JTC1/SC2, which standardizes coded 
character sets, sees its job as assigning codes to 
characters, not as saying anything about how 
those codes should sort"^. This is a reasonable 
attitude: collation is a surprisingly complex field, 
and to attempt to cover it in coded character set 
standards would break the ISO rule of one topic, 
one standard. This is all very well, but 9945-2 
needs somebody to do the work, and WG15 may 
end up doing it itself if pleas for help from else¬ 
where in ISO fail. 

More work is on the way: 1003.2a, the User 
Portability Extension to POSIX.2, was registered 
for ballot as a Proposed Draft Amendment 
(PDAM) to DP 9945-2, giving the international 
community a chance to say what it thinks of the 
idea of standardizing interactive commands such 
as vi and language processors like cc—or rather 
c89. 


Coordination 

The coordination arrangements which will 
make IEEE and ISO work on POSIX march for¬ 
ward in lock-step were almost complete before 
the small international rebellion on the matter of 
language independence made us stumble. (See 
below.) Because WG15 failed to register 1003.4, 
1003.5 and 1003.9 at this meeting, the plan must 
be adjusted, although little slippage should result. 
We’ll try to jump on board the revised plan at the 
next meeting. 


1. This material is not in the published IEEE std. 
1003.1:1988. 

2. You can buy a copy by calling IEEE customer 
service on +1 908 981 1393 (1 800 678 IEEE inside the 
U.S.) and giving them a credit card number. The cost 
is $37, plus $4 for overseas surface mail, plus another 
$15 for airmail. Alternatively, your national standards 
body may be able to sell you a copy. For example, BSI 
in the U.K. has them for sale at £24. 

3. DP 9945-2 is the last that we will see; under the 
new directives, DPs are no more; they are replaced by 
working drafts (WDs), which become committee drafts 
(CDs) before becoming DISs. This is not a big deal. 

4. For oblique confirmation from '‘the father of 
ASCII”, see 
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Internationalization 

In the one and a half days before the main 
meeting of WG15, its three rapporteur groups 
met. I attended the internationalization meeting, 
which had a hectic time of it: as the only rap¬ 
porteur group directly concerned with the current 
content of 9945-1 and -2, we had a lot of com¬ 
ments to sift through prior to the main meeting. 
This we did, by the skin of our teeth. Our con¬ 
clusions are largely reflected in the actions on the 
two drafts, reported above. 

Security 

The security rapporteur group is just getting 
off the ground. As with internationalization, ac¬ 
tivities scattered throughout JTCl have to do with 
security. But in contrast to the current situation 
for internationalization, for security there is a 
(very new) subcommittee, SC27. Conceivably, 
SC27 could define some all-encompassing ISO 
security model^ which would not suit POSIX and 
the work of 1003.6, which is eventually to be 
integrated into the 9945 standards. The rappor¬ 
teur group is doing all that it can to prevent this 
from happening. Happily, ISO is already aware of 
the issue, and has formed a special working group 
on security, to which WG15 will be sending a 
representative. 

Conformance Testing 

The proceedings of the rapporteur group on 
conformance testing were rather overshadowed 
by the announcement of Project Phoenix, Quite 
from what ashes this has risen we did not learn; 
however, as it involves cooperation between the 
Open Software Foundation (OSF), UNIX Inter¬ 
national and X/Open, it is difficult to resist the 
temptation to speculate. But resist I shall . . . 

The goal of Phoenix is to develop a common 
conformance testing suite and methodology for 
the three organizations, or, to put it another way, 
to harmonize their activities in this area. Harmo¬ 
nization of standards for open systems is an im¬ 
portant issue for WG15 in general. The issue 
affects the rapporteur group on conformance test¬ 
ing in particular because the European Commu¬ 
nity and NIST are giving a high priority to ac¬ 
crediting test houses which can check 
conformance to open systems standards. This 
means that they need to ensure that uniform test 


methods are being consistently applied. The rap¬ 
porteur group will address this issue at its next 
meeting. In the mean time, WG15 has registered 
the current draft of the first part of 1003.3, which 
describes general test procedures, and we will 
review it before our next meeting—despite the 
fact that there is as yet no well-defined route by 
which POSIX.3 can become an international stan¬ 
dard. 

Language Independence 

The issue of a making the POSIX standards 
independent of any particular computer language 
came to the fore at this meeting. What’s all the 
fuss about? Well, ISO has firm—and, in my view, 
sensible—ideas about how to write standards 
which define the services available from informa¬ 
tion processing systems. Building on the doctrine 
that one standard should address just one topic, 
there should be, says ISO, one document defining 
the service, and one or more documents describ¬ 
ing ways of accessing that service. For example, 
a browse through the open systems interconnec¬ 
tion standards reveals several groupings such as IS 
8072, Transport Service Definition and IS 8073, 
Connection oriented transport protocol specifica¬ 
tion’, and IS 8649, Service definition for the As¬ 
sociation Control Service Element, and IS 8650, 
Protocol specification for the Association Control 
Service Element^. Similarly, in text communica¬ 
tion, there is IS 9066-1, Reliable transfer—model 
and service definition and IS 9066-2, Reliable 
transfer—protocol specification, and in graphics, 
IS 7942, Graphical Kernel System functional de¬ 
scription and IS 8651-1 through -3 giving GKS 
language bindings for FORTRAN, Pascal and 
Ada. (8651-4, giving bindings for C, is in the 
works.) 

POSIX, ISO has ordained, must eventually 
go along with this model, with the result that IS 
9945-1, -2, and -3 (Operating system interface, 
shell and utilities, and administration respec¬ 
tively) will be concerned simply with defining ser¬ 
vices, and will not be bound to any particular 


5. ISO likes models, and they’re not without their 
uses. Work on a useful model for open systems is under 
way in several forums. 

6. Browsing through OSI standards may be a cure 
for insomnia. On the other hand, it may aggravate 
hypertension . . . 
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programming language. The key word here is 
“eventually”: because of the pressing need for an 
international standard for POSIX, a waiver has 
been granted, allowing the first version of the 
9945-1 and -2 standards to be a combination of 
(purists might say “a collision between”) a service 
definition and a C language binding to those ser¬ 
vices. The expectation is that a future revised new 
edition of each standard will be language- 
independent, and that bindings for the C language 
will be published as a separate standard at the 
same time^. 

So far, so good. But this is where the prob¬ 
lems start. While this mandated future appears a 
long way off if one looks at the IEEE’s work on 
POSIX. 1, it seems very close when POSIX,4 
(realtime extensions), POSIX.5 (Ada bindings) 
and POSIX.9 (FORTRAN-77 bindings) are con¬ 
sidered, In the case of POSIX.4, language- 
independent extensions are being proposed for a 
standard which is not itself (yet) language- 
independent. And POSIX,5 and POSIX.9 define 
bindings to a set of services which is not explicitly 
defined, but rather is defined implicitly in terms 
of the binding to the C language given in 
POSIX. 1. In the absence of a clear service def¬ 
inition, it is no surprise that, for good reasons 
which have to do with their respective languages, 
the Ada, C and FORTRAN versions of the op¬ 
erating system interface appear currently to be 
binding to slightly different sets of services. 

To some, the whole issue of language inde¬ 
pendence seems like an unnecessary and irksome 
imposition by ISO. In a recent posting to 
comp.sld.unix^^^, Doug Gwyn wrote: 

[Those of us who worked on 1003.1] did NOT set 
out to create a language-independent standard; C 
was specifically chosen for the obvious reason 
that it was the SOLE appropriate language for 
systems-level programming on UNIX, for a va¬ 
riety of reasons, including the fact that the UNIX 
kernel has a marked preference for being fed C 
data types. 


7. Under ISO’s procedures, the bindings standards 
for POSIX will be allocated an ISO standard number 
just as soon as we register a base document for one of 
them. Until that happens, I shall have to refer to “fu¬ 
ture bindings standards”, rather than having a conve¬ 
nient number to use as a handle. 


It is certainly true that, because, back in 
1985, all the base documents for the IEEE POSIX 
work were written in terms of a C language in¬ 
terface, the working group made a good prag¬ 
matic decision to produce a standard centered on 
C. A different decision would have resulted in the 
standard which took longer to get out of the door, 
and which would not have been any more useful 
to its primary audience—committed UNIX users 
concerned with the divergence among implemen¬ 
tations of their chosen operating system. But the 
success of UNIX and of its offspring, POSIX, has 
greatly widened the audience for the standard. 
Whether we like it or not, ISO has revisited the 
original decision so as to ensure that the inter¬ 
national standards for POSIX meet the needs of 
this new audience. As a result (to continue quot¬ 
ing from f^^): 

This “language binding” nonsense was foisted off 
on P1003 in an attempt to meet ISO guidelines. 

I think it must have been adopted by ISO as the 
result of Pascal types insisting that they never 
have to use any other language. 

Countering this, I would contend that, while 
the number of “Pascal types” is too small for their 
opinion to be of prime concern, the number of 
FORTRAN types, COBOL types and perhaps 
even of Ada types is large enough that it would 
be at least polite to provide some well-defined 
means whereby these communities can create 
bindings which allow them to hook into POSIX 
services without having to learn a new program¬ 
ming language. In the future, the growing C++ 
community may decide to define the interface to 
POSIX services in an object-oriented manner; 
Steve Carter paid us a flying visit with news from 
the ANSI X3J16 C++ committee in order to open 
up channels of communication. 

Consider another topic which has come to the 
fore as POSIX has moved into the international 
arena: internationalization—mechanisms which 
will allow non-English speakers to use POSIX- 
compliant systems without having to learn a new 
natural language. Like the current movement to¬ 
wards separating service definitions from bind¬ 
ings, this involves a considerable amount of work, 
yet does not appear to provide much that is of use 
to UNIX’ original community of technical users. 
Accommodating the preferences (prejudices?) of 
ever greater numbers of people is, it seems to me, 
part of the price of success for the UNIX oper- 
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ating system. And it may well pay dividends. For 
example, internationalization work on regular ex¬ 
pressions and collating has resulted in facilities 
which will be of use even to English speakers. 

Returning to the matter of the programming 
language used for bindings, it is true that AT&T- 
derived UNIX implementations prefer a diet of C 
data types. However, it certainly was an aim of 
1003.1 to allow hosted POSIX implementations, 
which might well be riding on underlying oper¬ 
ating systems with entirely different tastes. As a 
topical example, lightweight kernels such as Cho¬ 
rus and Mach live on messages, suggesting that 
their services could be bound to a data stream 
encoding®. I suspect that anybody who has tried 
to make ioctlQ work across a network wishes that 
UNIX had anticipated their needs by following 
such a model from the start. But it didn’t, and to 
redefine it in these terms would be a large piece 
of work which (thankfully) is a long way beyond 
the scope of WG15. 

There is no way in which all such require¬ 
ments could have been anticipated, and accom¬ 
modating the most important of them as the need 
arises inevitably causes pain. Both language in¬ 
dependence and internationalization are unantic¬ 
ipated requirements which the international com¬ 
munity wants retrofitted to POSIX on short order. 
And it’s ANSI, as provider of the base documents 
to ISO, and the IEEE, as the body accredited by 
ANSI to produce the documents, that get beat on 
to do the real work, and to suffer the pain. 

In the view of WG15, the real work needed 
to make POSIX. 1 a logical base for extensions 
such as POSIX.4, POSIX.5 and POSIX.9 is not 
being done fast enough. Trouble is, all standards 
are produced by volunteers—often volunteers 
who have had to make a case to their manage¬ 
ments that there’s some percentage in their com¬ 
pany being involved in standards work. There is 
clearly an eventual percentage in language inde¬ 
pendence for suppliers of POSIX-conformant sys¬ 
tems if it encourages users of languages not tra¬ 
ditionally found on UNIX systems to migrate to 
POSIX. But sadly, while not in any way criticizing 
the quality of the work done to date, there aren’t 
enough IEEE volunteers interested in recasting 
POSIX. 1 into language-independent form. 

Maybe, just maybe, if the international com¬ 
munity is more interested than the U.S. in getting 


this work done, WG15 should encourage more 
people from outside the U.S. to participate ac¬ 
tively and directly in the work of the IEEE. (Or, 
to put it another way, encourage more organiza¬ 
tions outside the U.S. to put their hands more 
deeply into their pockets in order to pay for peo¬ 
ple to attend IEEE POSIX working group meet¬ 
ings.) The alternative is that WG15 does the work 
itself—an alternative I’d rather not contemplate. 

For now, two action items on ANSI from 
WG15 sum up the situation: 

Pursue with vigour the production of a language- 
independent version of both 9945-1 and P1003.4 
in conjunction with a C language binding for each 
in order that they are eligible as replacements for 
9945-1:1990. 

Request the IEEE to expedite the completion of 
the language independent specification of 9945-1 
that is precisely functionally equivalent to the 
existing 9945-1:1990 and provide a C language 
binding that is syntactically and semantically 
identical; and request that a detailed proposal 
status report on this issue including a synchro¬ 
nization proposal be presented at the next meet¬ 
ing of WG15. 

Next Meeting 

The next meeting of WG15 is in Seattle from 
23rd to 26th October—the week after the IEEE 
POSIX working group meeting in the same city 
(and the same week as the EUUG meeting in 
Nice, France^). Should be interesting! 
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8. More ISO-speak: broadly, if you have a protocol 
that lives above layer five (session) of the OSI stack, 
you’d better call it a data stream encoding. For exam¬ 
ple, the protocol for the X Window System™ is a data 
stream encoding by this definition. 

9. In two meetings, WG15 has managed to clash 
both with summer USENIX and with autumn EUUG. 
It almost looks as if we do it on purpose! But we don’t, 
and will try to do better next year . . . 
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An Update on UNIX and C Standards Activities 

July and August, 1990 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


Report on U.S. TAG to ISO/IEC JTCl 
SC22 WG15 

Susanne Smith <sws@calvin.wa.com> reports 
on the June 1 meeting in Denver, Colorado: 

1. Overview 

Before you ask, ISO/IEC JTCl SC22 WG15 
is ISO POSIX. The U.S. TAG is the United 
States Technical Advisory Group, which formu¬ 
lates the U.S. position on WG15 issues and 
chooses the U.S. delegation to WG15 meetings. 

The TAG usually meets in conjunction with 
the IEEE POSIX meetings. The June 1 meeting 
was a special meeting, held to complete the many 
unfinished tasks left from Snowbird and ready the 
instructions to the U.S. delegation before the 
June 11 WG15 meeting. 

2. Two vacant positions 

Terry Dowling, vice-chair and security rap¬ 
porteur, resigned after the New Orleans meeting 
in January. Currently there are no candidates for 
the vice-chair position. Donn Terry has been as¬ 
suming the responsibilities in the interim. 

A rapporteur group is a group of technical 
experts that discusses specialized aspects of a par¬ 
ticular standards effort. The specialized aspects 
usually have a broader scope than an individual 
standard and require coordination of effort be¬ 
tween standards bodies. WG15 has three: inter¬ 
nationalization, security, and conformance. The 
TAG currently has rapporteurs for internation¬ 
alization (Donn Terry) and conformance (Roger 
Martin). John Hill and A1 Weaver said that they 
would be able to cover the June 11 security meet¬ 
ings in Paris. 

Some important decisions from Snowbird 
3.1 Profile groups get help 

SC22 asked WG15 to develop a plan to help 
groups writing profiles. (A profile is an applica- 


tion-area-specific set of pointers to standards. For 
example, P1003.10 is developing a supercomput¬ 
ing profile.) Wearing his WG15-convener hat, Jim 
Isaak drafted and submitted a “POSIX Harmo¬ 
nization Proposal”—a plan that gives profile 
groups a way to observe WG15 meetings and 
participate when their proposals are being con¬ 
sidered. The plan lists the responsibilities of both 
the “harmonization liaison” and WG15. The 
TAG approved the plan with comments, includ¬ 
ing changing “harmonization” to “coordination.” 
[Editor: I think “harmonization” is ugly, but it 
does parallel the “MUSIC” acronym that’s gain¬ 
ing ground in the UNIX, er, “Open Systems” 
arena.] 

3.2 Speeding international approval 

SC22 has asked all working groups doing 
development work in national bodies (for exam¬ 
ple, WG15 and IEEE P1003) to find a way to 
synchronize their national and international ef¬ 
forts. Such synchronization will help eliminate 
delays between national-body approval and ISO 
approval; it will also insure that both national and 
international bodies use the same text and speed 
achieving a broad consensus by circulating them 
in both bodies simultaneously. 

Donn Terry, TAG chair, and Jim Isaak 
shouldered the burden of developing the plan and 
submitted it at Snowbird. The meat of the pro¬ 
posal is the following synchronization process: 

• SC22 review and comment 

• IEEE balloting; document ready for broad 
comment 

• U.S. recommends CD registration be re¬ 
quested by WG15. (CD, Committee Document, 
is now used instead of DP Draft Proposal.) 

• CD comments fed to IEEE balloting; IEEE 
recommendations fed to CD process 

• IEEE final approval delayed until updated 
draft is suitable for DIS registration 
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• DIS and ANSI approval run in parallel; 
substantive feedback from DIS ballot creates an 
IEEE PAR 

Final authority to approve or reject the plan 
rests with SC22 and the IEEE Computer Society 
Standards Activities Board, but the TAG voted 
“No with binding comments,” objecting to a few 
details. If the problems listed below are fixed, the 
vote will automatically change to “Yes.” 

• Under the plan, TCOS/SEC documents, 
such as standards drafts and administrative status 
reports, would all be sent to WG15 and SC22 to 
encourage feedback before balloting. The plan 
would force TCOS working groups to use the 
JTCl format for draft documents. Currently 
POSIX documents use a unique TCOS format, so 
the TAG objected to this requirement but added 
the comment that the format should be one ap¬ 
proved by the ITTF (Information Technology 
Task Force, formerly, the “Central Secretariat”). 

• The TAG also objected to the requirement 
that TCOS meet outside of the U.S. mainland 
every 12 to 18 months to encourage international 
participation. It did not object to meeting outside 
the U.S., but thought the requirement did not 
belong in the plan. 

4. Decisions made in this meeting 

4.1 Formatting nits still block ISO UNIX 

The 9945-1 document (the ISO version of 
1003.1) still has problems. WG15 recommended 
registering it as an International Standard (IS), 
but is now stuck in a loop: ISO demands a format 
change, the IEEE makes the change, then ISO 
finds a new formatting problem. The TAG thinks 
this loop has gone on long enough, and recom¬ 
mended that WG15 form an ad hoc committee to 
determine what ISO will accept. 

4.2 P1003.1 updates go international 

WG15 is balloting to make 9945-1.2 (which 
corresponds to 1003.1a, draft 5) a Draft Interna¬ 
tional Standard (DIS). The TAG approved the 
U.S. position with comments. What’s that mean? 

Voting within WG15 is done by member 
country. To arrive at the U.S.’s position on a 
WG15 ballot, the TAG members draft a position 
then vote on it, one vote per corporation. (POSIX 
participation, in contrast, is by individuals.) The 


final ballot resolution is presented to WG15 as the 
U.S. position, Sometimes a voice vote suffices, 
but DISs, NPs (New Proposal, formerly New 
Work Item), or CDs (Committee Document, for¬ 
merly Draft Proposal), require a letter ballot. 

The initial letter-ballot vote was nine yesses, 
two noes (with comments), three abstentions; the 
two negative ballots were from Sun and AT&T. 
We considered three options for AT&T’s com¬ 
ments: 

1. do nothing and write a response to AT&T 
explaining why, 

2. pass the comments on to WG15, or 

3. pass the comments on to the 1003.1 working 
group, who could better judge their technical 
merits. 

We chose the third. In contrast, we incor¬ 
porated Sun’s comment into our position. Though 
someone suggested that AT&T might not be get¬ 
ting fair treatment, Sun’s comment (which simply 
noted that a change made in chapter eight was not 
reflected in chapter two), was only a response to 
the TAG ballot, while the AT&T comments were 
more far-reaching responses to 9945-1.2 itself and 
demanded a different forum. Nevertheless, the 
group asked the ad hoc committee reforming 
TAG procedures to reconsider the ballot resolu¬ 
tion process. 

4.3 How can you be two places at once (when 
you’re . . .)? 

In light of the amount of time TAG meetings 
keep members from attending working groups, 
we decided to meet Sundays before and Thurs¬ 
days and Fridays during the POSIX meetings. 
This new schedule will start with the Seattle meet¬ 
ing in October. The idea is to complete as much 
as possible on Sunday and have Thursday and 
Friday available if necessary. We agreed that the 
TAG should allocate this much time to avoid 
one-day meetings like this one. The SEC meeting 
schedule may force this to change; several TAG 
members are TCOS officers, committee chairs, or 
Institutional Representatives, all of which are au¬ 
tomatically SEC members. 

4.4 Last, least 

Both P1237 and X3T5.5 are working on re¬ 
mote procedure calls (RPC). X3T5.5 is specifying 
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the data stream encoding and P1237 is working on 
the Application Programming Interface (API). 
The TAG recommended that the API work be 
brought to the ISO level under the WG15 um¬ 
brella. 


Report on USENIX Standards Birds of 
a Feather (BOF) Session 

An anonymous correspondent reports on the June 
12 meeting in Anaheim, California: 

This snitch requests anonymity for several 
reasons, none of them related to his alcohol con¬ 
sumption during the BOF. The request actually 
relates to the snitch’s employer—a standards or¬ 
ganization. Because I am paid neither to file 
snitch reports nor to write opinions on standards, 
to submit this paper through normal channels for 
official, outside publication, even if it were en¬ 
tirely objective (or factual, for that matter), 
would require endless rounds of exhaustive, or¬ 
ganizational review. 

John Quarterman, of Texas Internet Cpn- 
sulting (TIC), and Susanne Smith, of Windsound, 
chaired the meeting, which was attended by about 
40 people, including Larry Wall—nearly a stan¬ 
dards body by himself. [Editor: Larry is the per¬ 
son responsible for such contributions to the com¬ 
munity as rn, patch, and perl.] Jeff Haemer was 
absent because “his wife is having a baby any day 
and I just don’t know where his priorities are!?” 
[Editor: Zoe Elizabeth Haemer, 61bs. lOoz., after 
a forty-five minute labor.] 

Quarterman started out by covering who he 
is, how to reach him, and what he does. [Editor: 
Sounds like it would have been valuable for me 
to attend.] Smith pointed out that TIC and Wind- 
sound have collaborated on a calendar that in¬ 
cludes all the latest dates of standards meetings. 
[Editor: Y ou can request copies from 
tic@tic.com. They span July 1990-June 1991, and 
cost $5.00, plus shipping, handling, and (Texans 
only) tax.] 

They briefly reviewed standards efforts of 
interest to USENIX members, including P1003 
(POSIX) and P1201 (Windowing). Quarterman 
discussed whose standard (ISO? ANSI? FIPS? 
other?) was most important but I was unable to 


draw any conclusions or coherently summarize it, 
so I’ll omit it here. Nonetheless he did get across 
two points: 1) there is a lot of coordination be¬ 
tween groups and 2) he is very quotable. (“The 
IEEE standards board is baroque and byzan- 
tine.”) 

After this basic informational introduction, 
the meeting was thrown open to the audience. 
The ensuing discussion was a mix of four things: 

1. Humor 

A couple of examples will give the flavor. 

• An overheard conversation: 

“Mach was the greatest intellectual fraud in 
the last ten years.” 

“What about X?” 

“I said intellectual.” 

• The announcement of the new Weirdnix 
contest: 

a contest for a correct interpretation of 
P1003.1 or .2 furthest from the original in¬ 
tent, The state of Utah is offering a trip for 
two to Salt Lake City for the winner. 

2. Opinion polling 

Quarterman tried to discern whether attend¬ 
ees thought they were being well-served by him, 
the USENIX Standards Watchdog Committee, 
and the USENIX position on standards: to at¬ 
tempt to prevent standards from prohibiting in¬ 
novation. Indeed, at the April POSIX meeting, 
he was told that smaller companies don’t like our 
participation because of this position. (For a more 
detailed discussion of the USENIX position on 
standards, see either ;login: 15(3):25 or the pe¬ 
riodic overview posting in comp.std.unix about 
the USENIX Standards Watchdog Committee.) 

Quarterman explained how USENIX came 
to its current policies and why it does not endorse 
standards of its own. Some audience members 
were unhappy with extant standards bodies and 
said they wouldn’t mind if USENIX played a 
more active role. Smith reminded us that Uni- 
Forum working groups, which she praised, play 
such a role. You are encouraged to let the 
USENIX Standards liaison and Board of Direc¬ 
tors know what you believe their position on stan¬ 
dards should be. 
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On a related note, BOF attendees were quite 
eager to be kept informed on standards issues. In 
this snitch’s opinion, this is probably the 
standards-related area in which USENIX most 
excels, and its contribution overshadows that of 
any other source that this snitch is aware of. The 
USENIX Standards Watchdog Committee pub¬ 
lishes copiously in both ;login: and the Usenet 
newsgroup comp.std.unix. Quarterman raised the 
possibility of breaking out the standards infor¬ 
mation of ;login: into a separate publication. 

Some attendees wanted increased coverage 
of standards currently outside of ;login:'s baili¬ 
wick, such as RS-232 and CD-ROM format. Un¬ 
fortunately, following any and all computer- 
related standards would exceed USENIX’s 
budget and resources. [Editor: The alert reader 
will have noticed Andrew Hume’s fine report on 
WORM-based file system standards last quarter. 
Send me a report. I’ll edit it.] 

Quarterman and Smith revealed that they are 
writing a book on UNIX-related standards (which 
will not be posted electronically). No suggestion 
was made for how it could stay up to date. 

3. Government-bashing (Who is NIST and why are 
they so out of control?) 

As soon as we determined that NIST wasn’t 
represented in the room and couldn’t defend it¬ 
self, it became fair game. (There were no OSF 
reps either as their BOF ran concurrently with 
ours—but no one knew what OSF was doing so 
we skipped insulting them.) 

Quarterman fanned the flames by giving an 
example where NIST had pushed too hard, in his 
opinion: System Administration. “Dot seven 
shouldn’t exist,” he said, but NIST pushed for it. 
Because government agencies view FIPS so fa¬ 
vorably that a system administration FIPS would 
quickly become a de facto standard for non¬ 
government users as well, the IEEE said “ok, let’s 
look at it.” 

Quarterman said things didn’t turn out as 
badly as they could have. Unfortunately there is 
little common practice or prior art in the area; 
fortunately, dot seven is coming along so slowly 
that there may be by the time it is ready to go to 
ballot. Moreover, dot seven’s work has encour¬ 
aged several companies and universities to work 


on the parallels between system administration 
and network management. Still, he reminded us 
that a standard should neither create nor innovate 
but only standardize, quoting Dennis Ritchie’s 
compliment to X3J11 in his keynote address: 
“The C committee took something that wasn’t 
broken, and tidied it up without breaking it.” 

The audience asked, “How do we control the 
activities of NIST?” NIST is a part of the gov¬ 
ernment. If you are a U.S. citizen, your tax dol¬ 
lars fund it, so you can write your congressperson. 
While you can communicate directly with NIST’s 
standards representatives, Quarterman asked that 
we not bug them in the name of USENIX, “be¬ 
cause I have to work with these guys.” 

If you feel bold, you can actually talk to John 
Lyons, the director of NIST— 
<lyons@micf.nist.gov>—who lies midway be¬ 
tween the scutpuppy standards reps and the de¬ 
monically powerful congresscritters. He really 
does read and answer his email (and his signature 
does say that his opinions represent those of his 
organization). 

Quarterman ended by defending, or at least 
rationalizing, NIST’s pro-active stance: “The pri¬ 
mary reason is money.” A familiar example is the 
Air Force’s AFCAC-251 RFP (Request For Pur¬ 
chase). This five-to-ten billion dollar request for 
SVR3-conforming systems created a heap of trou¬ 
ble by specifying a vendor brand name. After 
official protests, the procurement had to be re¬ 
worded at great expense—ultimately to you, the 
taxpayer. A vendor-independent, POSIX FIPS 
would have prevented this. 

One of the few questions Quarterman 
couldn’t answer was, “Why did NBS change its 
name anyway?” This snitch scraped away at the 
dirt and uncovered the explanation: 

The U.S. Department of Commerce under which 
NBS resides had wanted to change the name for 
many years because NBS has long performed 
activities quite unrelated to standards. As usual, 
it was politically hobbled for quite some time 
until a sufficiently obvious expansion of respon¬ 
sibilities came up for funding at which time (1/89, 
Reagan) the following announcement was issued: 

The new name, “National Institute of Standards 
and Technology,” reflects the broadened role 
and new responsibilities assigned to the agency 
which will include the traditional functions of 
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providing the measurements, calibrations, data, 
and quality assurance support to U.S. commerce 
and industry, together with several new programs 
to support the aggressive use of new technologies 
in American industry. NIST’s new purpose is “to 
assist industry in the development of technology 
and procedures needed to improve quality, to 
modernize manufacturing processes, to ensure 
product reliability, manufacturability, function¬ 
ality, and cost-effectiveness, and to facilitate the 
more rapid commercialization ... of products 
based on new scientific discoveries.” 

Several new programs have been created 
aimed at rapid transfer of technology to U.S. 
industry. They are: 

1. Regional Centers for the Transfer of Manu¬ 
facturing Technology; 

2. assistance to state technology programs; 

3. the Advanced Technology Program; and 

4. the Clearinghouse for State Technology Pro¬ 
grams, 

Call (301) 975-3058 (NIST Technical Infor¬ 
mation) if you would like more information on 
any of these programs or on NIST itself. 

4. Get involved in standards! 

This discussion went on for some time. UNIX 
is no longer guided by a few bright individuals; it 
is now in the hands of vested commercial inter¬ 
ests, some of which don’t care about innovation 
or good design. 

For the most part, the committees themselves 
contain intelligent, well-meaning people who re¬ 
ally want to create useful standards. But in a small 
committee, overlooked unintentional flaws can 
ruin otherwise good work. Snitches help forestall 
this by functioning as a community ear. If you 
don’t have time to be on a committee, get on the 
mailing list and continue to read the newsgroups 
so you can comment on critical issues when they 
arise. If you don’t, you have only yourself to 
blame if the standards come out all wrong. 


Report on IEEE 1003.0: POSIX Guide 

Kevin Lewis <klewis@gucci,dco.dec.com> re¬ 
ports on the July 16-20 meeting in Danvers, Mas¬ 
sachusetts: 


Dot Zeroes rite of passage 

For the first time in plenary, the group 
walked through the entire guide (221 pages), fine- 
tuning verbiage. This walk-through takes Dot 
Zero across a threshold: instead of soliciting con¬ 
tent to fill up empty sections, we are now filtering 
the text. I’m proud we’ve gotten this far. I re¬ 
member when we started this journey, virtually 
from scratch. 

By the time we finished the walk-through, we 
had found that more structure and parameters 
were needed: rules to make our walk-throughs 
more productive. I ended my last report with the 
statement, “let’s see if we have the self-discipline 
to get there.” Here is where some of that self- 
discipline comes in. We’ll see at the next meeting 
who abides by the rules we have agreed upon. 

New Volunteers for OS and UI Sections 

Two other good things happened in Danvers. 
Tricia Oberndorf is now in charge of the operating 
system section of the guide, Tricia is project 
leader for the Navy’s Next Generation Computer 
Resources Operating System Software Working 
Group, which has chosen POSIX as its base stan¬ 
dard. Heretofore, Jim Isaak had been the section 
leader. 

Martha (“Marti” ) Sczcur (pronounced “see- 
zur”), from NASA, and Ruth Hein, from AT&T, 
have picked up the user interface section, which, 
up until the April meeting, had lain untouched for 
almost two years. These are welcome resources. 
Both of these welcome volunteers made signifi¬ 
cant contributions to the user-interface section of 
the recently published draft 8—contributions 
woefully lacking in draft 7. 

What Will We Cut and What’s a Profile? 

In my last report, I stated that Dot Zero still 
faced hard decisions in two areas: guide content 
and profiles. I think guide content questions will 
resolve themselves as we move toward the mock 
ballot. Deadlines, like moving your household, 
have a tendency to make you throw away stuff 
that you otherwise might have kept. Given our 
goal of an early 1991 mock ballot, I think we will 
see a change in our “pack rat” mentality. 

You might be wondering what will be on the 
editing-room floor. I can offer two sections: Data 
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Interchange and Graphics, whose demise might 
come about due to a lack of interest by anyone in 
the committee to contribute to them and move 
them along. There also seems to be a lot of re¬ 
dundancy. Good examples of this are the sections 
I am responsible for: Introduction and Scope. The 
guide seems to say the same thing in each of these 
sections but struggles to make it sound different. 
The fine tuning efforts will root this out. 

We’re still debating profiles, but a consensus 
is forming around the term POSIX profile. Dot 
Zero agrees we must define such a profile, but its 
elements still elude us. (This gets into the debate 
about whether a “true” POSIX profile needs to 
include 1003.1. Right now, there is only one 
POSIX standard, and it would seem to make 
sense that a POSIX profile should include it. 
However, there are convincing arguments to the 
contrary, such as a profile that specifies 1003.2 
(shell and tools) compliance on DOS machines, 
which cannot support 1003.1.1 think POSIX pro¬ 
files should include some POSIX standard, but 
not any specific one.) Also, should Dot Zero 
make mandatory rules for profile writers, or just 
offer basic guidelines? These two topics will serve 
as the focus for much of our discussion in the 
October meeting. 

For uniform resolution of our debates about 
profiles, we will meet and coordinate with rep¬ 
resentatives of the other working groups, partic¬ 
ularly the profile groups. (Right now, that’s real¬ 
time, supercomputing, multiprocessing, and 
transaction processing.) This will also help ensure 
that we hear all issues and key points of view. The 
primary debate focuses on whether Dot Zero 
should attempt to put “teeth” into the guide. 
Does Dot Zero, because of its goal in providing 
guidance to profile writers, have any say about the 
legitimacy of current or future profiling efforts? 
How extensive should this guidance be? How 
does Dot Zero provide guidance in an area where 
it lacks technical expertise? These kinds of ques¬ 
tions frame the debate. [Editor: What do you 
think the answers are to these questions? Speak 
up. If you don’t go, and don’t have anyone else 
to tell, at least tell Kevin.] 


Report on IEEE 1003.4: Real-time 
Extensions 

Rick Greer <rick@ism.isc.com> reports on the 
July 16-20 meeting in Danvers, Massachusetts: 

Most of the action in the July dot four meet¬ 
ing centered around threads. The current threads 
draft (1003.4a) came very close to going to ballot. 
An overwhelming majority of those present voted 
to send the draft to ballot, but there were enough 
complaints from the dot fourteen people (that’s 
multiprocessing—MP) about the scheduling chap¬ 
ter to hold it back for another three months. 
Volunteers from dot fourteen have agreed to 
work on the scheduling sections so that the draft 
can go to ballot after the next meeting in October. 

Actually, dot four voted to send the draft to 
ballot after that meeting in any case, and the 
resolution was worded in such a way that a con¬ 
sensus would be required to prevent the draft 
from going to ballot in October. Thus, the MP 
folks have this one final chance to clean up the 
stuff that’s bothering them—if it isn’t fixed by 
October, it will have to be fixed in balloting. Some 
of us in dot fourteen felt the best way to fix the 
thread scheduling stuff was via ballot objection 
anyway. Unfortunately, the threads balloting 
group is now officially closed, and a number of 
MP people saw this as their last chance to make 
a contribution to the threads effort. The members 
of dot fourteen weren’t the only ones to be taken 
by surprise by the closure of the threads balloting 
group. It seems that many felt that it would be a 
cold day in hell before threads made it to ballot 
and weren’t following the progress of dot four all 
that closely. [Editor: I’ve bet John Gertwagen a 
beer that threads will finish balloting before the 
rest of dot four. The bet’s a long way from being 
decided, but I still think I’ll get my beer.] 

Meanwhile, the ballot resolution process con¬ 
tinues for the rest of dot four, albeit rather slowly. 
There are a number of problems here, the biggest 
being lack of resources. In gener^ll, people would 
much rather argue about threads than deal with 
the day-to-day grunt work associated with the 
IEEE standards process. [Editor: The meeting 
will be in Seattle, Washington. Go. Be a re¬ 
source.] Many of the technical reviewers have yet 
to get started on their sections. Nevertheless, pro¬ 
posed resolutions to a number of objections were 
presented and accepted at the Danvers meeting. 
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[Editor: Rick is temporarily unavailable, but Si¬ 
mon Patience of the OSF has kindly supplied 
these examples: 

The resolved objections were taken from the 
CRB: replacing the event mechanism by “fixed’’ 
signals, replacing the shared memory mechanism 
by mmapO and removing semaphore handles 
from the file system name space. Replacing 
events by signals was accepted; no problem here. 
Adopting mmapO got a mixed reception, partly 
because some people thought you had to take all 
of mmapO, where a subset might suffice. The 
final vote on this was not to ask the reviewer to 
adopt mmapO, which may not satisfy the objec¬ 
tors. I’d guess the balloting group will eventually 
hold sway here! Finally, the group accepted 
abandoning the use of file descriptors for sema¬ 
phore handles, but some participants wanted to 
keep semaphore names pathnames. The reviewer 
was sent off to rethink the implications of this 
suggestion.] 

We should be seeing a lot more of this in 
Seattle. Similar comments apply to the real-time 
profile (AEP) work. The AEP group made more 
progress over the last three months than the tech¬ 
nical reviewers did, although even that (the AEP 
progress) was less than Pd hoped. We’re expect¬ 
ing our first official AEP draft in October. 

Report on IEEE 1003.10 and 1003.15: 
Supercomputing and Batch 

An anonymous correspondent reports on the July 
16-20 meeting in Danvers, Massachusetts: 

P1003.10 Supercomputing AEP 

Scope synopsis: write an Application Envi¬ 
ronment Profile (AEP) for supercomputing, and 
work with other POSIX groups to define addi¬ 
tional interfaces where required. 

What an AEP is and what it must contain are 
still under development—making it impossible to 
know when the work will go to ballot. POSIX. 10 
met two separate times in Danvers with POSIX.0 
(which is writing a “guide for profile writers”) and 
other profile groups. 

While we all agree that a profile is a list of 
standards, other aspects are unclear. For exam¬ 
ple, it was asserted previously that AEPs must be 
ISO Standardized Profiles (ISP), but it was sug¬ 


gested in July that there may be a POSIX Stan¬ 
dardized Profile (PSP), or maybe a Preliminary 
PSP (PPSP). 

POSIX.0 is also undecided about whether an 
AEP should contain conformance testing infor¬ 
mation, or what might comprise such information. 
If extensive conformance testing is required for 
the 50-plus standards cited in the current 
POSIX. 10 draft, the effort could take many years. 

Whatever the decisions, the progress 
POSIX.0 and ISO make in defining an AEP is the 
upper bound on the progress any profile group 
can achieve. 

In Danvers, POSIX. 10 looked again at the 
numerical accuracy issues, including a proposal to 
ANSI X3T2 from DEC called a Language- 
Compatible Arithmetic Standard (LCAS), which 
may or may not be useful to supercomputing. 
POSIX. 10 will request formal liaison with X3T2 
to ensure that we keep current with developments 
in this area. The conflict between portability and 
performance improvements from proprietary for¬ 
mats is not easy to resolve, but is of paramount 
interest to numerical, supercomputing applica¬ 
tions. This issue will not go away, though it may 
be impossible for the first release of this profile to 
make any meaningful statements about it. 

This working group also discussed Jim Isaak’s 
article, “Application Environment Profiles: a Sig¬ 
nificant Tool for Simplification and Coordination 
of the Standards Efforts” (IEEE Computer, Feb¬ 
ruary 1990). Not only must profiles be complete, 
says Jim, they must be coherent. A profile may 
need to act like a glue, specifying not just lists of 
standards, but interactions of different standards 
on a single system. 

The working group will put all the standards 
it cites into a triangular matrix to identify poten¬ 
tial interactions. As each interaction is identified, 
the group will examine the effects on coherence 
by looking more closely at parameters, options, 
and behaviors, to determine if additional interface 
standards are required. 

POSIX. 10 must also pass proposals for stan¬ 
dards extensions on to other working groups. A 
proposal for an Application Program Interface 
(API) for checkpoint and restart has been sub¬ 
mitted to POSIX. 1; they returned it with a re¬ 
quest for substantial modification, but this writer 
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understood them to agree that they will polish and 
ballot the interface. A proposal for a resource- 
limits API is also in preparation, and will be 
discussed further at the next meeting. Proposals 
for a resource reservation system, a removable/ 
non-sharable media system (nine-track tape, car¬ 
tridge tape, CD-ROM, etc.), and resource ac¬ 
counting also need to be done. 

These interfaces need to be done soon, be¬ 
cause the batch group (POSIX. 15) needs the under¬ 
lying functionality to support batch processing. 

P1003.15 Supercomputing Batch Extensions 

Scope synopsis: define API, user commands 
and system administration commands for a net¬ 
worked batch queueing system; current draft is 
based on NQS sold by COSMIC at Univ. of Ga. 

POSIX. 15 has the same chair as POSIX. 10 
(Karen Sheaffer from Sandia Livermore), but 
now has a separate vice chair and secretary. The 
group has grown to 15-20 regular participants in 
the batch discussions, and now includes active 
participation by more vendors. 

Their latest draft is very close to the page 
layout of the other POSIX documents, which is 
important for acceptance by the other groups. Jim 
Isaak spoke to the group in Danvers, and helped 
them to understand the balloting process and the 
relation of their Program Authorization Request 
(PAR) both to their own efforts and to the efforts 
of other groups. 

A very important and thorny issue for this 
group is the definition of a host-to-host request/ 
reply protocol. In the first place, there are no 
other POSIX host-to-host protocols that this 
group can use as a model for how to write its spec. 
Secondly, numerous participants are dissatisfied 
with the NQS protocol: it simply doesn’t carry 
enough information. HP, in particular, is working 
very hard to ensure that the load balancing as¬ 
pects of their Task Broker system are not ex¬ 
cluded by anything in the batch standard, and for 
that they need more information to be exchanged 
between hosts. 

Another problem facing this group is the lack 
of an API for resource limits, resource reserva¬ 
tion, and resource accounting beyond basic UNIX 
accounting. Based on the balloting in POSIX.2, 


they can expect balloting objections against state¬ 
ments in their document which refer to these 
features until the interfaces are in place. 

Just before the close of the meeting, a rep¬ 
resentative of POSIX.7 presented some questions 
about the current direction of the batch effort and 
its relation to the Palladium print system (the 
Athena print system used at MIT). Many current 
NQS sites queue print requests with NQS, and 
there has been some interest in defining printing 
features. That function, however, is clearly within 
POSIX.7’s scope. It is reasonable for POSIX.7 to 
question if and how Palladium and NQS are com¬ 
patible. 

POSIX. 15 meets eight times a year, with in¬ 
terim meetings about midway between the quar¬ 
terly POSIX meetings. It would be in their in¬ 
terest to publicize these meetings, and to arrange 
them through the IEEE. (Following the October 
POSIX meeting, there will be one December 4-6 
in Huntsville, AL hosted by Intergraph.) 

There is reason to be optimistic about the 
progress of this group. Although they’ve only 
been an official POSIX group for one meeting, 
they are showing an increased sensitivity to the 
political issues involved in getting their document 
through balloting. I think their biggest liability 
right now is their determination to go to ballot in 
January 1991. The date seems premature by a 
year or more; they need more meetings before 
balloting so more people can read and comment 
on their draft. 


ERRATA 

On page 53 of the July/August 1990 issue of 
;login: it was stated that the problem with com¬ 
press is that the algorithm is copyrighted. A 
reader (Mike Stump) pointed out that the prob¬ 
lem is that there is a patent on the algorithm. 

-JSH 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a 
new group and publishing information on local groups in ;login:. At least one member of the group 
must be a current member of the Association. Send additions and corrections to login@usenix.org. 


CA - Fresno: the Central California UNIX Users 
Group consists of a WMcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufreslgordon (209) 298-8393 


CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 ^^ Monday of each 
month. 

Rich Bergstedt, AT&T (714) 727-5231 

8001 Irvine Center Dr., Suite 224 
Irvine, CA 92718-2900 

UUASC Information Line (714) 727-5232 

CO - Boulder: the Front Range UNIX Users Group 
meets monthly at different sites. 

Steve Gaede gaede@sda.com 

Software Design & Analysis (303) 499-4782 

P.O. Box 3521 
Boulder, CO 80303 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2"^** Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 

(sun,novavax,gould} !sunvice!tony 
j mclaughlin@sun.com 

John O’Brien (305) 475-7633 

gatech!uflorida!novavax!john 


FL - Jacksonville/Northeast: UNIX Users of Jack¬ 
sonville meets the 2“^ Thursday of each month. 

Tom Blakely (904) 646-2820 

uflorida!unf7!tfb 

Emilie Olsen (904) 390-3621 

FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3^*^ Wednesday of each 
month at the Florida Institute of Technology. 


Bill Davis (407) 242-4449 

bill@ccd.harris.com 


FL - Orlando: the Central Florida UNIX Users 

Group meets the 3^** Thursday of each month. 

Mike Geldner (407) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (407) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (407) 869-2462 

{codas,attmail}!mikel 


FL - Tampa Bay: the Tampa UNIX Users Group 
meets the Thursday of each month in Largo. 

Bill Hargen (813) 530-8655 

uunet!pdn!hargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 


GA - Atlanta: meets on the 1®^ Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastem Mich¬ 
igan Sun Local Users Group meets jointly with the 
Nameless UNIX Group on the 2“*^ Thursday of each 
month in Ann Arbor. 

Steve Simmons home: (313)426-8981 

scs@lokkur.dexter.mi.us ofl&ce: (313) 769-4086 

K. Richard McGill Bill BuUey 

rich@sendai.ann-arbor.mi.us web@applga.uucp 

MI - Detroit/Ann Arbor: dinner meetings the 1®^ 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 

MN - Minneapolis/St. Paul: meets the Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 

17130 Jordan Court pnessutt@nis.mn.org 

Lakeville, MN 55044 (612) 895-7007 
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MO - St. Louis: 

St. Louis UNIX Users Group Eric Kiebler 

Plus Five Computer Services plus5!sluug 

765 Westwood, lOA (314) 725-9492 

Clayton, MO 63105 


NE - Omaha: meets the 2“*^ Thursday of each 
month. 

/usr/group nebraska Kent Landfield 

P.O. Box 44112 kent(®ugn.uucp 

Omaha, NE 68144 (402) 291-8300 


New England - Northern: meets monthly at differ¬ 
ent sites. 

Peter Schmitt 

Peter.Schmitt@dartvax!dartmouth.edu 
Kiewit Computation Center (603) 646-2085 

Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian pep@Princeton.EDU 

Dept, of Computer Science (609) 452-6261 

Princeton Univenity 
Princeton, NJ ol'i44 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy. com 


OH - Columbus: The Columbus Local UNIX 
Group meets the Monday of each month. 

Mark Verber verber@mps.ohio-state.edu 

Physics Department (614) 292-8002 

Ohio State University 
Columbus, OH 43210 


OK - Tulsa: the Tulsa UNIX Users Group, $USR, 
meets the 2nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsixlsmason@drd.com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


PA - Philadelphia: the UNIX SIG of the Philadel¬ 
phia Area Computer Society meets the morning of 
the 3rd Saturday of each month. 


G. Baun, UNIX SIG rutgers!{bpa,cbmvax)! 

c/o PACS temvax!pacsbb!{gbaun,whutchi) 

Box 312 

La Salle University 
Philadelphia, PA 19141 


TX - Austin: CACTUS meets the 3""* Thursday of 
each month. 

Capital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 

ofl&cers@peyote.cactus.org 

James Johnson (512) 331-3781 

jjhnsn@cs.utexas.edu 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX-Houston: the Houston UNIX Users Group 
(Hounix) meets the 3^"^ Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix.uucp 

TX - San Antonio: the San Antonio UNIX Users 
meets the 3^** Thursday of each month. 

Jeff Mason gatech!petro!hpsatb!jefF 

Hewlett Packard (512) 494-9336 

14100 San Pedro 
San Antonio, TX 78232 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
P.O. Box 820 

Mercer Island, WA 98040-0820 
uw-beaver!tikal!camco!bill 


Washington, D.C.: meets the Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 350 
Vienna, VA 22182 

Alan Fedder (703) 448-1908 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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